1) Field of the Invention
The field of the present invention relates to diagnostic and maintenance tools for control networks.
2) Background
Electronic control systems are commonly used in a number of manufacturing, transportation, and other applications, and are particularly useful to control machinery, sensors, electronics, and other system components. Manufacturing or vehicular systems, for example, may be outfitted with a variety of sensors and electrical and/or mechanical parts that may need to be activated, deactivated, monitored, enabled, disabled, adjusted or otherwise controlled when needed to perform their predefined functions. Control of the various system components is generally accomplished by providing suitable electronic signals to various actuators, relays, switches, or other control points within the system. Control systems often require that processes be carried out in a prescribed order, or with a level of responsiveness, that precludes sole reliance on manual control. Also, such systems may employ sensors or other components that require continuous or periodic monitoring or control, and therefore lend themselves to automated or semi-automated control.
A variety of different network architectures for controlling electronic systems have been developed or proposed. Examples of various control networks include programmable logic controller (PLC) based multiplexed control systems in which a single central processing unit (CPU) is used to control a number of input/output (I/O) modules or network nodes; network-controlled multiplexed control systems in which a network of interconnected CPUs are used to control a number of I/O modules at the various network nodes; and hierarchical, master-slave multi-bus control systems, wherein CPU-driven network nodes are connected together at each bus level in a loop configuration.
In most control networks, it is necessary to be able to diagnose operational problems that may occur within the system. Operational problems may result from wiring faults, component failures (either in the control network or in the components being controlled by the control network), or logic flaws, among other reasons. Also, it may be necessary to test the operation of the controls system from time to time, such as when components are added or removed, or when functionality of the control system is added or changed.
Traditionally, diagnosis and testing of a control network is carried out by manual activation of switches, relays.or actuators, and observing the results on the input/output devices of the control system. Conventional meters (e.g., an Ohm-meter) may be used to determine if electrical signals from the control network are reaching the intended destination(s). Due to the different types of operational problems that can occur (e.g., wiring fault vs. component failure), and the myriad of possible places in which a fault or failure could occur, locating the source of an operational problem can be an extremely slow and laborious process. With the increasing complexity of control systems and the steadily growing number of components used in such systems, diagnosis and testing become even more critical and, in many respects, more difficult.
To conduct a complete manual test or diagnosis of a control system can be very time consuming and tedious. The test personnel generally need to read complicated circuit blueprints and locate each relay, switch, actuator or other component that needs to be tested. Often, multiple relays, switches or actuators will need to be activated, switched or otherwise positioned to test a particular system component. In such a case, the test personnel needs to locate and set each such relay, switch and/or actuator to its proper position, which can be a lengthy process. In many control systems, simply locating the appropriate switches, relays or actuators can be difficult, especially if the control system is complex and includes many components. Also, particularly in the case of on-board control systems used in vehicles (such as buses or rail cars), the switches, relays or actuators can be located in inconvenient places and thus hard to find or set to reach manually.
Diagnosis and testing of a control network is sometimes carried out by connecting a test computer (usually a laptop or other portable computerized device) to a diagnostic and maintenance port of the control network. The test computer is generally programmed to receive various types of information from the control network to allow an operator to monitor the functioning of the control system. The test computer may also be used to download new programming instructions to the control network via the diagnostic and maintenance port.
An illustration of a test computer set-up for monitoring a control network is illustrated in FIG. 1. As shown in FIG. 1, a vehicle 101 (shown in phantom for convenience of illustration) has a control network 110 (shown in solid, dark lines) with various I/O modules dispersed throughout the vehicle 101. A test computer 103 connects by a cord 106 to a module 112 containing the diagnostic and maintenance port. The test computer 103 is thereby able to monitor the functioning of the control network 110.
FIGS. 2, 3 and 4 are diagrams of test computer set-ups for different control networks as known in the art. FIG. 2 illustrates a hierarchical, master-slave control network 120, having a master bus controller (MBC) 125 connected to a common bus 138, which connects various network nodes in a loop configuration. The network nodes may include, for example, high-speed cell net controller (HCNC) modules 128 and digital input/output (DIO) modules 127, or other types of modules, all of which generally operate in a slave mode with respect to the common bus 138. The control network 120 may also include one or more secondary buses (not shown). Further information about certain types of hierarchical, master-slave control networks may be found in U.S. Pat. No. 5,907,486 and Japanese Patent documents 10-326259 and 10-333930, all of which are assigned to the assignee of the present invention and hereby incorporated by reference as if set forth fully herein. The control network 120 may be physically connected to a test computer 123 from time to time through an RS-485 compatible diagnostic and maintenance port 129, for the purpose of testing and monitoring the functionality of the control network 120 as generally described above.
FIG. 3 is a diagram of a PLC-based multiplexed control system 140, in which a single main central processing unit (CPU) 146 is used to monitor and control a number of network nodes 150. Each network node 150 typically includes a programmable logic controller (PLC) which, in turn, monitors various input signals or conditions (such as temperature, current, speed, pressure and the like) and generates output signals to various output devices (such as actuators, relays or switches) through input/output (I/O) modules 152, thus providing localized control at various network node sites. The main control network CPU 146 communicates with the PLCs of each of the network nodes 150 over a main system bus 147, and provides top-level command and control. The main control network CPU 146 may be physically connected to a test computer 149 from time to time through an RS-232 compatible diagnostic and maintenance port 148, for the purpose of testing and monitoring the functionality of the control network 140 as previously described.
FIG. 4 is a diagram of a network-controlled multiplexed control system 160 in which a network of interconnected CPUs 170 are used to control a number of I/O modules 172. A main CPU 166 is connected to other dispersed CPUs 170 over a control area network (CAN) bus or device net 167. The CAN bus or device net 167 may be physically connected to a test computer 169 from time to time through a CAN bus or device net gateway 175, which connects to the CAN bus or device net through a CAN bus or device net test port 168. Testing or monitoring of the functionality of the control network 160 may thus be carried out, as previously described.
While the use of a computer to monitor the functioning of a control system has some advantages, present systems have limitations and drawbacks. For example, the test computer generally must be kept close to the diagnostic and maintenance port, due to the cord 106 (as shown in FIG. 1) connecting the test computer to the diagnostic and maintenance port. This arrangement physically limits where the test personnel can view relevant information. Thus, test personnel working at the back of the vehicle 101, for example, could not view the information being shown on the test computer 103. Therefore, the test personnel would need to walk back and forth between the test computer 103 and the pertinent locations of the vehicle 101 in order to carry out an ongoing test or diagnostic procedure. Further, the test personnel often need to refer to complicated circuit blueprints to interpret the information on the test computer 103 and to locate the various locations of interest within the control network 110 of the vehicle 101. Such blueprints are usually in paper form and are cumbersome to deal with. Cross-referencing between the circuit blueprints and the information on the test computer 103 takes extra time and effort on the part of the test personnel, and may be the source of human error in conducting a test or system diagnosis. Further, the types of testing, monitoring and diagnosis that can be conducted using a test computer 103, at least as conventionally practiced, are limited.
Some systems for wireless diagnosis or monitoring have been proposed in contexts such as diagnostic analysis of an automobile or similar vehicle. Examples of such wireless systems may be found in U.S. Pat. Nos. 5,758,300 and 5,884,202. Conventional wireless diagnostic and monitoring systems typically involve a portable wireless unit that is specifically configured for a single type of application. Therefore, such portable wireless units are useless for monitoring systems other than the type for which they are specifically configured. Creating a custom portable wireless unit for each type of control network can be expensive and time-consuming. Also, despite being wireless, the type of information and test functionality they provide is limited, and most, if not all, such wireless systems do not have the functionality to operate in the context of a sophisticated control network.
Therefore, a need presently exists for a flexible, versatile and simple to use test and diagnosis tool suitable for either simple or complex control network systems.